\section{Process Management}

\subsection{Mechanism}

\begin{frame}[containsverbatim]
  \frametitle{An Overview}
\begin{verbatim}
       +------------------------------+   +-----+
       | P_M                          |---| P_H |
       |  +---+  +---+  +---+  +---+  |   +-----+
       |  | T |  | T |  | T |  | T |  |
       |  +---+  +---+  +---+  +---+  |
       |           |      |      |    |
       +-----------|------|------|----+
                   V      V      V
                   +-------+  +-----+
                   |  P_C  |  | P_C |
                   +-------+  +-----+
\end{verbatim}
  \begin{tabular}{ll}
    \verb|P_M|: Main Process & \verb|P_C|: Container Process \\
    \verb|P_H|: Helper Process & \verb|T|: (kernel / monitor) thread
  \end{tabular}
\end{frame}

\begin{frame}
  \frametitle{The Main Process}
  The tasks the main process accomplished is listed below.
  
  \begin{enumerate}
  \item Initialization.
  \item Being the container of kernel threads and monitor threads.
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Monitor Threads}
  Monitor threads are used to :

  \begin{enumerate}
  \item handle signals. \\
    The container process will stop when it receives any signal which is treated as an interrupt request in umUcore, let its monitor thread know, and the monitor thread calls the handler.
  \item intercept syscalls. \\
    The container process will stop right after it has requested a syscall to the host system (before the syscall is executed), and the monitor thread nullify the syscall it made to the host, let the host finish the useless work, and finally complete what should be done to umUcore.
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Container Process}
  A user process in umUcore are running in the container process on the host system so that it really has its own virtual memory space. At present, the threads of the same group share one container on the host.

  The kernel doesn't appear in container processes. A page of stub code and a stub stack, which are used to make syscalls under the control of its monitor thread, is mapped instead. So the user processes have no access to any kernel code or data except the stub area.
\end{frame}

\begin{frame}[containsverbatim]
\begin{verbatim}
+------------------------------+
|       Host Kernel Area       |
+------------------------------+ <--- HOSTBASE
|        ** Invalid **         |
+------------------------------+ <--- KERNBASE / USERTOP
|                              |
:       ~~~~~~~~~~~~~~~        :
|                              |
+------------------------------+ <--- USERBASE
|        ** Invalid **         |
+------------------------------+ <--- STUB_END
|      ** Stub Stack **        |
+------------------------------+ <--- STUB_DATA
|       ** Stub Code **        |
+------------------------------+ <--- STUB_CODE
|        ** Invalid **         |
+------------------------------+ <--- 0
\end{verbatim}
\end{frame}

\begin{frame}[containsverbatim]
  \frametitle{Stub Code And Stack}
  Some operations are only required by the kernel, while they must be done by the container itself (eg. mmap/munmap). The stub code is used to accomplish these tasks. Arguments and return value of the call is read or written on the stub stack, which is visible to both the kernel and the container.

  See \verb|arch/um/include/stub.h| for details of the stub stack.
\end{frame}

\begin{frame}
  \frametitle{Helper Process}
  The process on the host system needed by the 'keyboard driver' is the only helper process in umUcore at present.
\end{frame}

\subsection{Visit User VM Space In the Main Process}

\begin{frame}
  \frametitle{Why It Is Different}
  As user processes in umUcore are running in container processes, the main process have no direct access to any user vm space while many syscalls have arguments which are pointers to user space.
\end{frame}

\begin{frame}
  \frametitle{Solution}
  UmUcore currently use a simple implementation to solve the problem:
  
  \begin{enumerate}
  \item Read or write to any word to the page by using stub code. \\
    This will make the page ready if it is not present, and the bits of the page entry will be set properly.
  \item Get the offset of the page from the page table and read/write that page. \\
    Since the whole 'memory', which is a temporary file actually, is mapped in the main process, it is possible to access the page in this indirect manner.
  \end{enumerate}
\end{frame}